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Inthe 5th Conputer Networking Conf erence 
papers David Cheek, WASMWD, included in his 
submission an attatchment containing the Pacgram 
Protocol Definition. Inthis paper you will find 
the latest revision of that Pacgram Protocol 
Definition wth a synopsis of Pacgram\s creation, 
where itis at now, and where [hope it will go in 
the anateur packet radio community. 


BEG NNI NGS 


Pacgram's beginnings date back to the good 
old days of the BETA board tests. It was 
recognized early on that we were going to require 
sone standard method of passing Radiogram traffic 
via packet radio. Though the Radiogram form has 
been in use for nany years, the way in which it is 
used varies from one network to another and from 
one node to another. In this I mean that each 
net work has its own particular way of presenti ng 
the contents of the Radiogram over the air for a 
receiving station to copy. 

Each network has developed a method that best 
suits its needs based on the particularities of 
the network. Voice traffic nets present the 
Radiogram contents by reading the Radiogram slowly 
and in chunks or _ logical prouPss stopping at 
predefined breakpoints for fills or varification. 
CW traffic networks have a similar method varying 
slightly to suit the needs of the CW operators 
net work. 

With this in mind it only nade sense that the 
packet radio network, with its totally different 
conditions, would need to develop its om net hod 
of presenting Radiogram traffic. To this brings us 
the need for a set of objectives to be strived for 


cr met when designing our new protocol. 


OBJECTIVES 


0 Provide a ‘standard’ 


The most important of all is to 
design a messaging protocol that would be 
the standard that all packet radio 
traffic would follow. To accomplish this 
would require that the protocol suit all 
the needs of the traffic handelers. 


148 


Michigan 48106 


User readable without software 


Since the equi pment and capabilities 
of each packet radio station varies, it 
would be desirable that the protocol use 
only printable characters so that traffic 
handelers that did not have Pacgram 
software would still be able to operate 
within the network. 

Though a little nore difficult when 
originating traffic, it would be a simple 
task ‘when receiving or forwarding a 
Pacgramto decode the fields by hand or 
simply receive the message to disk for 
later re-transmission. 


Compatable with other net wor ks 


Any traffic handler know’ that a 
piece of traffic can travel through any 
number of different nets before reaching 
its destination. These nets nay be 
Packet, RITY, CW, or Voice traffic 
net wor ks. 

This requires us to keep in mind 
any limitations that these other networks 
may have when we are originating and even 
when forwarding traffic. Pacgram must be 
designed to filter out any non-printable 
characters along with a nunber of the 
conputer keyboard characters that cannot 
be sent in CW or RTTY modes. 


Not machine dependent 


The Pacgram messagin pr ot ocol 
should not have any machine dependancies. 


The protocol should not require a 
specific type of terminal, computer, 
hardware, or screen format. A_ session 


layer protocol can be implemented at each 
Pacgram station to handle these 
dependancies. This session layer has been 
inpl emented in the current CP/M version 
of a ie to su pot ADM3 style consoles 
like the Xerox-820 


Reduce operator workload 


eee ee 


An important gain in utilizing 
conputers istoallowthe conputer to do 
as nuch of the tedious work as possible. 
Wen implementing Pacgram ve should have 
the software perform automatic word 
counting, logging, filing, etc. 

(Please refer to David Cheeks paper 
in the 5th Conputer Networking Conf erence 
on page 5.115.) 


The '‘KISS' principal seens to appl y 
to everything. An important objective is 
to keep the Pacgram protocol as simple as 
possible without giving up important 
options such as future growh — and 
expansion. 


For war dabl e 


Since a message forwarding network 
is already in place we should maintain 
compatability with it. We should also 
keep in mind future network designs. 
Pacgram being simply a string of text 
characters allows us to upload, dow oad, 
and nake use of the autonatic mail 
forwarding features of the WORLI type of 
Packet Bulletin Board Systens. 

Maybe future PBBS's could contain 
Pacgram pre and post-proccessors for 
users that did not have Pacgram softwere, 
This would allow them to originate and 
receive Radiogram traffic while the 
backbone network utilized the Pacgram 
protocol . 


Expandabl e 


Pacgrams design shoul d include the 
ability to be expanded and adopted into 
other applications. One of — these 
applications nay be a softwere interface 
that extracts Pacgram fields and inserts 
theminto a database, 

As you will see, the | atest revision 
of the Pacgram protocol allow for 
forntypes other than the ARRL Radi ogram 
so database applications can be extremely 
flexible. 


o Automatic or Unattended 


ee ed 


Pacgram implementations have been 
written that allow for automatic receipt 
of traffic. Thiscan be extremely handy 
when the operator cannot be at the 
terminal at all times such as during an 
ener gency situation. Qt her 
implementations could allow automatic 
printing of all Radiogram traffic to 
hardcopy as they are received while at 
the same time saving all other packet 
activities to disk. 


COD| NG THE PROGRAM 


With these objectives in mind | started 
writing a terminal program that contained the 
Pacgram messaging protocol. The project started 
out being written in BASIC since nearly every 
conputer has a BASIC interpreter and that would 
allow a greater nunber of machines to support 
Pacgram But this failed miserably when it was 
determined that BASIC simply was not fast enough 
wWthout being compiled, and this certainly would 
limt the number of users due to the lack of BASIC 
conpilers for many of the smaller computers. 

This |ead me to write the Pacgram Terminal 
Program in 8080 assenol y code to run under (CP/M. 
This would limit the use of Pacgramto only CP/M 
nachines and others that could emulate CP/M such 
as the |BMPC, Apple, and sone Connodores. 

Programing started inFebruary 1984 with 
software tests both in the Detroit and Dallas 
areas, followed by many _ re-writes and updates. 
Refinements were made to the protocol as problem 
areas were uncovered. 


| MPROVEMENTS 


Recent improvements have been to seperate the 
Area Code into its own field to allow for 
destination sorting based on Area Codes. The 
addition of the Formtype field to identify the 
type of formcontai ned within the Pacgram This 
allows us to not only send ARRL Radiogram traffic 
but Civil Defense traffic as well. Not to nention 
other forntypes that may be required for special 
events such as Footraces and Bikethons and 
dat abases. 

And finally, the addition (but not yet 
implemented) Application Level Acknow edgenent. 
Since our only acknow edgenents are at the Link 
layer, there was no way of guarenteeing that the 
Pacgram was properly captured by the receiving 
station so an additional verification is being 
consi der ed. 

For more details on the Pacgram protocol, see 
the Pacgram Protocol Definition that follows at 
the end of this paper. 
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It is hoped that peediann will eventually 
catch on as the standard for Radiogram, Ener gency, 
and/or Database messaging. The protocol is still 
developing but appears to be quite dependable and 
stable at its current revision. 

As for the future, good new. Inthe ARRL 
FIELD FORUM dated J anuary 1987, after a meeting of 
the Eastern Area Staff of the National Traffic 
System in Williamsburg, Virginia, the following 
resolution was published: 


"THEREFORE, the Eastern Area Staff 
RECOMVENDS that the Eastern Area Staff 
Packet Committee continue its work 
towards defining a strategic traffic 
system which integrates packet, and 

FURTHERMORE, the Eastern Area Staff 
will implement, inthe near term the 
following National Traffic System usage 
of packet for a trial period of two 
years: " 


I and. FURTHERMORE, the Eastern 
Area Staff recommends the use of the 
PACGRAM nessage fornat, as described by 
the 5th Networking Conference, during the 
trial period. " 


It is hopefull that the NTS Eastern Area 
Staff willuse the noust current revision of the 
Pacgram nessage format as published below. 


[ Pacgram Protocol Definition ] 
(Versions 2.0.3 and _ later) 


By: Jay Nugent WB8TKL 
3081 Braeburn Circle 


Ann Arbor, Michigan 48108 


(313) 9714076 


Dat ed: 860813 
Copyright 1984 ,86,87 


PACGRAM is an application software package that runs on the host 
computer connected to a TNC. The PACGRAM software is responsible f or 
prompting the operator for the proper Radiogram information one field 
at a time and forns a PACGRAM nessage from this. The message can then be 
sent to the TNC for transmission into the amateur packet net work. 

Q the receiving end, PACGRAM decodes the data stream fromthe TNC 
for the starting characters of a PACGRAM When it finds these characters 
it receives the rest of the nessage and can later decode it back into the 
Radiogram fornat for display on the console, or printed on the printer. 
Received PACGRAMS are stored in buffer space and/or disk files and nay 
be later retransmitted or forwarded to other stations in the network. 

Special characters are used within the PACGRAM to signal the start 
of the PACGRAM nessage, the end of the PACGRAM nessage, and to seperate 
the fields of information within the PACGRAM nessage. 

These control characters and the protocol are described in the 


following definition. 


soecs PACGRAM CONTROL CHARACTER and PROTOCOL DEFINITION 


The control characters, and character sequences, used in PACGRAM 
were based on the unlikelihood that they would ever appear in any part 
of a normal Radiogram.. Consideration of the CW traffic nets that may 
handle nessage traffic generated with PACGRAM vas also taken into 
account since many characters cannot be sent using CW 

For those stations not possesing PACGRAM software, these control 
characters were selected so that a PACGRAM can be read directly f rom 
a terminal and written back into the standard Radi ogramformvery easily 
by hand. A Fornsnode has been added to the protocol to allow the sending 
of a directly printable PACGRAM This enables any station to receive a 
PACGRAM already fornatted to be printed on hardcopy. This form of PACGRAM 
uses its own starting sequence that can be easily detected by a small 
computer running BASIC. Once the start sequence is detected, it can then 
route all out put to the printer. The standard end of PACGRAM character 
is used to indicate the end of the print so that the output can then 


be routed back to the console. 
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---- The START of a PACGRAM shall be a pound si gn '#! followed by an 
asterisk '*', 


The purpose of this character sequence is to signal the start 
of a PACGRAM and differentiate it from any other data sent by the 
TNC to the host computer. Such as other communications udia or 
commands and responses fromthe TNC. 

The start of the PACGRAM sequence was altered inthe second 
release of this provocol inan effort to avoid false starts caused 
by WLI like PBBS's that use the # character in their data. 


--+- The FORMTYPE sequence shall be 'ARL' for ARRL Radi ogramfornat and 
shall always be three characters in length followed by the DELIN- 
| ATION character. 


The purpose of this three letter sequence is to identify the 
formtype that is contained withinthe Pacgram For the standard 
ARRL Radiogram form this sequence is set to ARL. Applications 
requiring message formats other than ARL may define their ow 
field nares and order and define theirown three letter Formtype. 

(This change has been nade for releases 2.0.0 and above) 


---- The DELI NATION character shall be an asterisk '*'. 


This character is present in the PACGRAM to deliniate the 
Radi ogram fields from one another. The absense of data in any 
one of the fields will cause two consecutive asterisks to 
appear wthin the PACGRAM No filler characters are placed between 
the asterisks of an enpty field. 


---- The FIELD ORDER of an ARL PACGRAM is as follows. 


NUMBER / PRECEDENCE / HANDELI NG INSTRUCTIONS / STATION OF ORIGN 
CHECK / PLACE OF ORIGN / TIM FILED / DATE FILED 


NAME TO / NUMBER & STREET / CITY / STATE / ZIP / AREA CODE / PHONE NUMBER 
TEXT OF THE MESSAGE 
S| GNATURE / TITLE OF SI GNEE 


Note: The CITY and STATE fields have been seperated into two 
individual fields. This allows for automated routing based 
on the destination City and State. Area Code was seperated 
for the sane reason. 


---- FIELD LENGTHS and TYPES wthin the ARL PACGRAM 


The Nunber field will be limited to 8 characters maximum. 
The Check field will be limited to 10 characters maxi mum 
(This has been expanded to handle ARL type checks) 

The Text field is limited to a nmaxinumof 1024 characters. 

All other fields are limited to 60 characters. 


Fields nay contain either alphabetic or nuner ic characters but 
those characters that cannot be sent using CWwill not be al lowed. 


Such as the follow ng: 
# - Pound si gn * - Asterisk & - Amperand 


%- Percent € - Left arrow > - Right arrow 

= - Equals “« - Carat - Underscore 

All control characters including Carriage Return, Linefeed, and 
For nf eed. 


Any non-allowed characters found wthin a Pacgram will be discarded. 
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---- The END of a PACGRAM shall be the anpre sign'&'. 


The purpose of this character is to signal the end 
of the PACGRAM 


---- The START of a FORMSMODE PACGRAM shall be '#PAC*' followed by 
a carriage return. 


The purpose of this starting sequence (including the carriage 
return) is to signal the start of a PACGRAM in the FORMSMODE. 
A small conputer running a simple BASIC program can trap this 
starting sequence and then direct all its output to a printer. 


---- The END of a FORMSMODE PACGRAM shall be an anpre sign '&' followed 
by a carriage return. 


The purpose of the end of FORMSMODE sequence is to signal the 
end of a FORMSMODE PACGRAM A small conput er ianing 4 BASIC 
programcan trap this sequence and then direct its out put back 
to the console. 


---- Proposed Application Level Acknowledgement shall be as follows: 
#* ACK* Number *Pr ecedence*Hx*Station of Origin& 


The purpose of the Application Level Acknowledgement is to 
confi rm to the sending station, in a positive manner, that a Pacgram 
sent by it to another station has in fact been received by the 
distant station. 
Note the Startpac sequence followed by ACK to indicate acknowledgement. 
The NUMBER, PRECEDENCE, HX, and STATION fields are echoed back by the 
ee ne station for comparison to SENT Pacgrans. A natch confirms 
which SENT Pacgram has been acknowledged. It can then be flagged as 
ACKnowledeged and logged. 

The NUMBER and STATION fields should never be repeated within any 
operating year so the likelihood of an incorrect ACK is very unlikely. 


As a Radiogram has well defined fields in a specific order, so does 
the PACGRAM. The order in which the fields occur in the Radiogram is the 


exact order that they will appear in the ARL PACGRAM For example, here is 
a sample Radi ogram followed by its equivelent data stream in PACGRAM form 


NUMBER: 126 ROUTINE WB8TKL CHECK: 5 ANN ARBOR MI 14302 MAY 21 
TO: MIKE NUGENT 
123 HOLLYWOOD AVE 
HOLLYWOOD, CAL 54321 
(818)555-1234 
TEXT: HOW IS THE WEATHER X 
SIGNED: JAY 


And the equivelent in ARL PACGRAM form would be: 


#*ARL*126*R**WBETKL*S*ANN ARBOR MI*1430Z*0521*MIKENUGENT*123 HOLLYWOOD AVE 
*HOLLYWOOD*CAL*54321*818*555- 1234*HOW ISTHEWEATHERX*JAY*& 


The proposed Application Level Acknowledgement to this would be: 
#*ACK*126*R**WBETKL& 


As you can see, the length is well within 256 bytes, tne maximum 
AX. 25 packet length. Even with the Paclen set to 256, a single packet 
could contain a fairly large text field. Shorter Paclens can be used 
as network conditions require. The Pacgram will simply be re-assentbl ed 
back into its original formframe by frame. 

You can see the benefits of using PACGRAMs over the voice or CW net hods 
of sending traffic. This packet can be sent inj ust a fraction over one 
second at 1200 bps, an enormous improvement over existing amateur traffic 
systens. Pacgramalso prompts the operator for the fields inthe correct 
order, sofewer mistakes are nade. 

Also notice in my example, that since I left the fields for Handling 
Instructions and Title blank, that PACGRAM simply put no data bet ween 
the two asterisks. This is neccessary to maintain the field count for 
decoding of the PACGRAM at the receiving end and also wastes as little 
of the transmission bandwidth as possible. 


Happy Packet ing -WB8TKL 
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